User-Friendly Failure Diagnosis

Many programs have named configuration options. If users misunderstand what an option does, or type the name wrong, the program will malfunction. These malfunctions are configuration errors and often result in error messages. Even when an error message is uniquely caused by a particular problem, it may not tell the user how to proceed. Bad error messages are a major problem in configuration debugging [3]. Past debugging techniques rely on changing the underlying environment to get more details about the failure [2]. This is a deployment problem in many contexts. Users don’t want to install new software when something is broken. They want to know how to fix it. Their usual habit is to search for the error message. But what if there isn’t a good diagnosis available online? We propose to substitute automation for human expertise in interpreting errors. We suggest a process by which developers can make their error messages more useful. Our past work has shown how to do this with static analysis [1]. We propose to reuse the concept of an error attribution table, but build it in a completely unrelated way. Rather than use static analysis, we think dynamic failure injection could work better for some classes of errors. Importantly, because the two techniques share an output format, the results can be joined together synergistically. BODY Crash the system every-which-way with failure injection. Build table of error messages. When users hit trouble, look up error msgs in table.